Task: Understand The Assignment (AST)
Purpose
To obtain insight into the (project) organisation, the aim and purpose of the system development process, the system or package to be tested and the requirements to be met, so that better direction can be given to the other steps in the planning.
Relationships
RolesPrimary Performer: Additional Performers:
Outputs
    Process Usage
    Main Description

    Method of operation

    The method of operation covers the following steps:

    1. Identifying accepters, using acceptance criteria and other information providers
    2. Examining the available documentation
    3. Conducting interviews

    In practice, this task is carried out in parallel with the formulation of the assignment. It is also somewhat underestimated. Specifically, the test manager may speak to too few stakeholders, although it is essential in the beginning to measure expectations adequately and, as test manager, to ‘put the feelers out’ in all directions. This is necessary in order to be able to carry out the steps effectively and to manage the test process successfully in the future.

    Products

    This task delivers the following parts of the test plan:

    • Stakeholders and acceptance criteria - The stakeholders relevant to the testing and their acceptance criteria
    • Norms and standards - The standards employed are cited here. As regards testing, these can involve instructions issuing from the Testing line organisation, the master test plan or generic test agreements, TMap, TPI or test manuals. Development standards, document standards or quality norms that have to be or will be followed are also possibilities.
    • Basis of the test plan - Here the documents are mentioned that form the basis of this test plan. For example, a master test plan, project plan, specific project or test plans, a specific or a generic test method, generic test agreements, an implementation plan or other documents that are of importance.

    Techniques

    Checklist ‘Understanding the assignment’

    Steps
    1. Identifying accepters, using acceptance criteria and other information providers
    Usually the client is not the only stakeholder who has to accept the system; there are generally others, and it is important to clarify who these accepting parties are. This is done in consultation with the client. In practice, the test manager gets an opportunity here to discuss with stakeholders at a high level in the organisation (steering group members) and to interpret their opinions and expectations. Often there is no other opportunity for this, unless the test manager is in the (unfortunately) rare position of regularly participating in the steering group discussions. It is important to establish which accepters are to be provided with information directly or indirectly during the project by means of test reports. It should also be clear what requirements or acceptance criteria each accepter is proposing. These are the minimum qualitative requirements that the product must meet to make it satisfactory to the accepter. For the sake of clarity: the gathering of acceptance criteria is not the responsibility of the testers, but it is input into the setup of the test process. Acceptance criteria can be very diverse. Some examples are:

    • Qualitative criteria as regards product and generation process, e.g. the number of defects that may remain open
    • Criteria as regards the environment, e.g. the infrastructure should be installed or the users should have followed a training course
    • Criteria in the form of (the detailing of) requirements of the product, e.g. ‘an order should be processed within X seconds’.

    Not all the acceptance criteria are relevant to testing.

    Besides accepters, various other parties/individuals can supply the test process with relevant information.

    2. Examining the available documentation
    The documentation provided by the client is examined. If the system development process relates to maintenance, then the availability and usability of existing testware is also investigated.
    3. Conducting interviews
    The various parties involved in the system development process are interviewed.

    The test manager asks the stakeholders questions concerning, besides the general background of the system to be tested and the process to be followed:

    • Their expectations about the results of the testing – what do they hope to see as the end result? This may relate to business processes supported by IT, realised user requirements or use cases, change proposals, critical success factors, cited risks (to be covered) but also, for example, that the new system should have at least exactly the same functionality as the old system (therefore no regression). These are referred to as the test goals. Do they fit with the test goals of the master test plan?
    • Does the interviewee have an idea of what the characteristics are (usually the quality characteristics) and object parts that operate in the above? Some people are able to answer this very well, but it may be too complex for others. The test manager has to estimate how much detail the discussion will allow.
    • What is the test basis, if any, that may or should be used later on as proof that the test was thorough enough?
    • What is the risk estimate of the test goals and/or characteristics/object parts? A risk is defi ned here as the product of Damage x (Chance of defect x Frequency of use). Often the interviewee will only be able to mention particular aspects of a risk, such as the Damage, the Frequency of use or the Chance of a defect. That doesn’t matter, for it can be expanded upon in the next step, the product risk analysis.
    • Does the stakeholder wish to be reported to, and if so, at what level? A point of focus here is that the number of types of reports should remain somewhat restricted for practical reasons. If necessary, the test manager should discuss this with the client.

    It is also advisable where possible to consult those indirectly involved. For example, the EDP auditors, the implementation manager, the future maintenance organisation, etc.

    The test manager feeds back the findings of this activity to the client for verification.

    More Information
    Checklists
    Guidelines

    Copyright © 2006, Sogeti Nederland B.V. All rights reserved.